Layer 1 — outer BP loop:
  `BeliefPropagationProblem` / `BeliefPropagationAlgorithm` /
  `BeliefPropagationState` (iterative, `<: AIE.NestedAlgorithm`)

Layer 2 — one sweep over edges:
  `BeliefPropagationSweepProblem` / `BeliefPropagationSweepAlgorithm` /
  `BeliefPropagationSweepState` (iterative, `<: AIE.NestedAlgorithm`)

Layer 3 — single-edge message update:
  `MessageUpdateProblem` / `SimpleMessageUpdateAlgorithm` /
  `MessageUpdateState` (non-iterative, overrides `AI.solve_loop!` —
  same shape `BPApplyGate` uses in the gate-apply code)

Every layer subtypes `AI.Problem` / `AI.Algorithm` / `AI.State`
directly. No `Union{...}` shortcuts — each layer's `initialize_state` /
`initialize_state!` / `initialize_subsolve` is its own method. The
`StopWhenConverged` dispatches accept `AI.Problem` / `AI.Algorithm` /
`AI.State` since `StopWhenConverged` itself is the unique
disambiguating type.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

API first, then the three layers from outer (BP) to inner (message
update), then the supporting `StopWhenConverged` stopping criterion +
`iterate_diff` helper, then the low-level kwarg utilities at the bottom.
Reads as "what's the API → how it's composed → supporting pieces" the
way the file is most likely to be skimmed.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

`StopWhenConverged` is fully generic — its dispatches accept
`AI.Problem` / `AI.Algorithm` / `AI.State`, with `StopWhenConverged`
itself as the unique disambiguating type. The only piece that needed
to live in BP was the metric: the BP `iterate_diff(::MessageCache,
::MessageCache)` override.

AIE now owns: `StopWhenConverged`, `StopWhenConvergedState`, the four
`AI.*` overloads, and a bare `iterate_diff(a, b)` verb that throws by
default. BP provides its concrete `AIE.iterate_diff(::MessageCache,
::MessageCache)`. The top-level `ITensorNetworksNext` namespace
re-exports `StopWhenConverged` + `iterate_diff` for callers that use
the package-qualified names.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Edges shouldn't be stored at both the outer BP algorithm level (as the
algorithmic edge-ordering choice) and the sweep algorithm level (as
runtime data that gets copied into the sweep problem). Keep them only
on `BeliefPropagationAlgorithm`; the outer `initialize_subsolve` then
transfers them into the `BeliefPropagationSweepProblem` when stepping
down.

`BeliefPropagationSweepAlgorithm` is now just `message_update_algorithm`
+ `stopping_criterion` (the stopping criterion is sized to the edges at
construction time in `beliefpropagation()`).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

The file now defines three problem/algorithm/state triples plus the
top-level `beliefpropagation` entry point, so the old name is misleading.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Public-API changes:

  * `beliefpropagation` no longer takes a `maxiter` kwarg; pass either
    `stopping_criterion = (; maxiter = 10)` or a full criterion such as
    `stopping_criterion = AI.StopAfterIteration(10) | StopWhenConverged(1.0e-10)`.
  * The `message_update_algorithm` kwarg accepts either a NamedTuple of
    keyword arguments forwarded to `SimpleMessageUpdateAlgorithm`, or a
    full `AI.Algorithm`.
  * The `edges` kwarg defaults to `default_beliefpropagation_edges(factors)`
    rather than being computed inside the body.
  * Per-iteration kwarg broadcasting (`extend_columns`, `rows`,
    `rowlength`, `repeat_last`) is removed.

Internals:

  * `BeliefPropagationSweepAlgorithm` now holds a single
    `message_update_algorithm` (was a `Dict{Edge, ...}` of per-edge
    algorithms). Edge-dependent updates are expressed by defining a new
    `AI.Algorithm` subtype and dispatching on `problem.edge` in
    `solve_loop!`.
  * `BeliefPropagationAlgorithm` holds a single `sweep_algorithm` (was a
    `Vector` of per-iteration sweep algorithms). Iteration-dependent
    sweep behavior is expressed by defining a new sweep algorithm
    subtype and varying the inner algorithm in
    `AIE.initialize_subsolve` using `state.iteration`.
  * New `select_*` selectors `select_beliefpropagation_stopping_criterion`
    and `select_message_update_algorithm`, modeled on
    `MatrixAlgebraKit.select_truncation`, normalize NamedTuple-or-object
    inputs into algorithm/criterion objects.
  * `default_beliefpropagation_edges` and
    `default_message_update_algorithm` expose the defaults as named
    functions.
  * Stopping-criterion default removal: the entry point no longer
    constructs a `StopAfterIteration(maxiter)` itself — choice of
    criterion is entirely the caller's responsibility, except for the
    inner sweep, which still defaults to `StopAfterIteration(length(edges))`.
  * Type parameter `SCState` renamed to `StoppingCriterionState` on both
    BP state structs.
  * Helper definitions reordered so default/select helpers sit above
    `beliefpropagation` for readability.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Reorder the body of `beliefpropagation` so the algorithm construction
flows top-to-bottom and `cache` is constructed alongside the
`AI.solve` call, and collapse a few short multi-line forms onto single
lines where the formatter is happy with it.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

…m` strategy

The third `AlgorithmsInterface` layer (`MessageUpdateProblem` /
`SimpleMessageUpdateAlgorithm` / `MessageUpdateState`) was a non-iterative
function call dressed in problem/algorithm/state ceremony; this commit
drops that framing. The per-edge update body lives in
`AI.step!(::BeliefPropagationSweepProblem, ::BeliefPropagationSweepAlgorithm,
::BeliefPropagationSweepState)` and delegates to a new strategy interface:

  - `abstract type MessageUpdateAlgorithm end`
  - `message_update!(algorithm, cache, factors, edge)`
  - `SimpleMessageUpdate <: MessageUpdateAlgorithm` (the default;
    holds `normalize` + `contraction_alg`)

`BeliefPropagationSweepAlgorithm` now holds a `message_update_algorithm`
field (default `SimpleMessageUpdate()`) and is no longer a
`NestedAlgorithm`.

Algorithm selection follows `MatrixAlgebraKit.select_algorithm`. Generic
`default_algorithm(f; kwargs...)` and `select_algorithm(f, alg; kwargs...)`
helpers live in `AlgorithmsInterfaceExtensions`; operations register a
default by overloading `default_algorithm(::typeof(f); kwargs...)`. BP
overloads both for `message_update!`. Callers can pass either an explicit
`MessageUpdateAlgorithm` instance, a `NamedTuple` of keyword arguments
forwarded to the default algorithm, or `nothing` plus flat kwargs (also
forwarded to the default). A convenience signature
`message_update!(cache, factors, edge; alg = nothing, kwargs...)` routes
through `AIE.select_algorithm` so the same dispatch pattern is reachable
from a free-standing call. The `message_update_algorithm` kwarg on
`beliefpropagation` uses the same selector.

To keep the message-store iterate persistent across outer-loop iterations
without duplicating it on the outer state, introduce an `AIE.NestedState`
abstract type with generic `getproperty` / `setproperty!` /
`propertynames` forwarders for `:iterate` through a `:substate` field.
`BeliefPropagationState <: AIE.NestedState` now wraps a
`BeliefPropagationSweepState` as `substate`; the outer state holds no
`iterate` field of its own. The default `AIE.finalize_substate!` (which
copies `substate.iterate` back to `state.iterate`) becomes a self-write
through the forwarder — harmless and removes the need for a BP-specific
override.

Rename: `BeliefPropagationAlgorithm.sweep_algorithm` field →
`subalgorithm` (matches the generic name already used in
`AIE.initialize_subsolve`'s return tuple).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Refine the MAK-style algorithm selector introduced in the previous commit:

* `select_algorithm` / `default_algorithm` now take an `args` tuple as
  their final positional argument (after `alg`). A generic value→type
  wrapper forwards `(::Tuple)` to `(::Type{<:Tuple})`, so operations
  dispatch on the input-tuple type. Wrapping in a tuple keeps the value
  and type domains disjoint — `(1.2,)` is unambiguously a value tuple,
  `Tuple{Float64}` is unambiguously the type form. This matters at sites
  like `beliefpropagation` where not every input has a concrete value
  yet (no specific `edge`), and the type-form call simply passes
  `edgetype(factors)` in its slot.

* New `AIE.AbstractAlgorithm` supertype carries the
  generic "passthrough an explicit algorithm instance" overload of
  `select_algorithm`, so each operation doesn't have to repeat that
  method. `MessageUpdateAlgorithm <: AIE.AbstractAlgorithm`.

* BP call sites updated: `beliefpropagation` constructs the cache earlier
  and uses `Tuple{typeof(cache), typeof(factors), edgetype(factors)}` as
  the args type. The per-call `message_update!(cache, factors, edge; ...)`
  uses the value tuple `(cache, factors, edge)`. Both describe the same
  call shape.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

…_criterion

`message_update!` now follows the convention of mutating-functions returning
the object they modify (the message cache), so callers can chain it.

`select_beliefpropagation_stopping_criterion` accepts a `tol` keyword in
the NamedTuple form alongside the existing `maxiter`. Either or both may be
specified; when both are given they are combined with `|` (stop on
whichever fires first). The spin-ice test now uses the NamedTuple form
`stopping_criterion = (; maxiter = 10, tol = 1.0e-10)` to exercise this
path, in place of the explicit `StopAfterIteration | StopWhenConverged`
construction.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>